All-Ones netmask is not needed for ACLs or flow logging #4440
+26
−167
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@eriknordmark Do you remember what was the use-case of the |
The DHCP server deployed by EVE for Local Network Instances assigns IP addresses to applications with a /32 netmask (all-ones) and uses the Classless Static Route Option (RFC 3442) to configure static routes for the NI subnet. This setup enforces routing even for east-west (app-to-app) traffic, which would otherwise only be forwarded if the actual NI subnet mask (e.g., /24) were used. This approach was historically implemented to prevent east-west traffic from bypassing ACLs and to ensure that connection tracking (conntrack) entries were created for flow logging purposes. However, it became unnecessary after we enabled the "net.bridge.bridge-nf-call-iptables" option, which ensures that even traffic forwarded by a bridge within EVE passes through iptables filtering and has conntrack entries created. Using a /32 netmask now offers no added value and has some drawbacks. First, applications may use DHCP servers with the Classless Route option disabled, resulting in obtaining all-ones netmask with no reachable destinations due to missing connected routes. Second, enforcing routing adds extra packet processing steps for traffic that could be directly forwarded between applications, increasing overhead and reducing network performance. We previously added an option to disable the all-ones netmask (while still keeping it enabled by default), but this has increased code complexity since it requires two distinct routing configurations to manage (and test). I propose removing the all-ones netmask configuration altogether to simplify the code and reduce packet processing overhead. While some may consider this a breaking change, I believe the change in the netmask should not impact applications as long as IP addresses are preserved and the overall routing/bridging functionality remains consistent across EVE upgrades (the set of reachable destinations does not change). Signed-off-by: Milan Lenco <[email protected]>
milan-zededa
force-pushed
the
remove-all-ones-netmask
branch
from
ded61d4
to
0cf9169
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The DHCP server deployed by EVE for Local Network Instances assigns IP addresses to applications with a
/32netmask (all-ones) and uses the Classless Static Route Option (RFC 3442) to configure static routes for the NI subnet. This setup enforces routing even for east-west (app-to-app) traffic, which would otherwise only be forwarded if the actual NI subnet mask (e.g.,/24) was used.This approach was historically implemented to prevent east-west traffic from bypassing ACLs and to ensure that connection tracking (conntrack) entries were created for flow logging purposes. However, it became unnecessary after we enabled the
net.bridge.bridge-nf-call-ip(6)tablesoption, which ensures that even traffic forwarded by a bridge within EVE passes through iptables filtering and has conntrack entries created.Using a
/32netmask now offers no added value and has some drawbacks. First, applications may use DHCP servers with the Classless Route option disabled, resulting in obtaining all-ones netmask with no reachable destinations due to missing connected routes. Second, enforcing routing adds extra packet processing steps for traffic that could be directly forwarded between applications, increasing overhead and reducing network performance.We previously added an option to disable the all-ones netmask (while still keeping it enabled by default), but this has increased code complexity since it requires two distinct routing configurations to manage (and test). I propose removing the all-ones netmask configuration altogether to simplify the code and reduce packet processing overhead. While some may consider this a breaking change, I believe the change in the netmask should not impact applications as long as IP addresses are preserved and the overall routing/bridging functionality remains consistent across EVE upgrades (the set of reachable destinations does not change).
This PR is part of a series of network performance optimizations coming into EVE, see documentation (will be submitted in a separate PR)